<HTML>

<!-- This is a hypertext file. -->
<!-- Either view it using a hypertext browser, such as NCSA Mosaic, -->
<!-- or ignore the html markup tags enclosed in angle-brackets -->

<TITLE> Intermud PROTOCOL </TITLE>
<H1> PROTOCOL </H1>
<P>

I have used the following protocol for the encoding of data mappings
into a single (string) packet for sending via the UDP port:
</P> <LISTING>
	HEADER1:data1|HEADER2:data2|HEADER3:data3 etc.
</LISTING> <P>
A list of macros defining standard headers is included in udp.h.  If
the field DATA is present in the mapping to be encoded, it is always
placed at the end of the encoded packet.  On decoding, everything
appearing after the DATA header will be interpretted as the DATA field.
 This avoids problems of having special characters appearing in main
DATA body of the packet, and hence the DATA field should always be used
to store the main body of any packet.
</P> <P>
Additional "custom" fields for use by request modules can be included
in the data mapping.  They will be decoded and passed to the request
module as normal, but will be ignored by the inetd itself.  By
convention lower case names are used for custom fields while upper case
is reserved for system fields.
</P> <P>
The fields NAME, UDP_PORT (and ID if necessary) will be automatically
added by the inetd on encoding as they are necessary for security
purposes by the receiving inetd.  The REQUEST field is invariably
necessary if the request is to be proccessed by the receiving end. 
SENDER is mandatory if a reply is expected (and you want it to actually
get back to you!), and any REPLY request should quote the original
SENDER in its RECIPIENT field.  The received ID should also be returned
in any REPLYs made.
</P>

</HTML>
